The clone(source, false) performs a shallow clone. However, the transform function mutates the source object deeply (e.g., by modifying source.root and source.functions). This can lead to incorrect TypeScript type generation because generateTypes will receive a partially modified object. A deep clone is required here to ensure the type generator works on a pristine copy of the source.

The current implementation of inferExpressionType uses broad regular expressions (/\bstring\b/.test(...)) to detect types. This can lead to incorrect type inference. For example, an expression like next.foo === "a string value" would be incorrectly inferred as type string instead of unknown (since it's a complex boolean expression).

The logic should be more conservative. It should only infer a primitive type if the expression is just that type's name (e.g., string). The resolveFunctionReferenceType method already handles this case correctly for single-word expressions. The regex-based checks for string, number, boolean, and any are redundant and error-prone, and should be removed. The function should rely on oneOfType and resolveFunctionReferenceType for simple cases and fall back to unknown for anything more complex, as documented in the README.

  inferExpressionType(expression) {
    if (!_.isString(expression)) return 'unknown';
    const parsed = this.parseConstraint(expression);
    const expr = parsed.expression;

    const oneOfType = this.oneOfType(expr);
    if (oneOfType) return oneOfType;

    const funcType = this.resolveFunctionReferenceType(expr);
    if (funcType) return funcType;

    return 'unknown';
  }

The propertyName function fails to properly escape single quotes and backslashes when wrapping a property name in single quotes. An attacker who can control the keys in the input YAML file (e.g., through a malicious pull request to a repository using fireplan) can inject arbitrary TypeScript code into the generated output file. If this generated file is subsequently imported into a project or processed by tools that execute code from TypeScript files, it could lead to arbitrary code execution. Using JSON.stringify is a safer way to handle property names that are not valid identifiers, as it correctly escapes special characters and wraps the string in double quotes.

Strip encrypted key annotations before emitting TS properties

The generated type keys currently use raw YAML key names for non-wildcard children, so Fireplan annotations like /encrypted or /encrypted[...] are emitted as part of the property name instead of being removed. In schemas that rely on encrypted path annotations (which transformBranch strips before building runtime rules), the .d.ts no longer matches actual Firebase paths and will type-check against incorrect field names.

Useful? React with 👍 / 👎.

Escape quoted property names in generated type literals

propertyName wraps non-identifier keys in single quotes without escaping, so a valid Firebase key containing an apostrophe (for example owner'sName) produces invalid TypeScript syntax in the generated .d.ts. This causes downstream TS compilation/parsing failures for schemas with such keys.

Useful? React with 👍 / 👎.

Avoid emitting duplicate string index signatures

When an object contains both a wildcard child and .more: true, this always appends a second string index signature ([key: string]: any) even though typeString already emitted one for the wildcard entry, so the generated .d.ts contains two [...: string] signatures and fails TypeScript compilation (TS2374). This breaks the documented wildcard+.more scenario instead of widening the wildcard type.

Useful? React with 👍 / 👎.

Keep any-typed properties optional unless required

This forces every property inferred as any to be required in the generated type, even when the schema does not use the required keyword. In Fireplan rules, child presence is only enforced via required, so schemas like foo: any are valid when foo is absent, but the emitted type incorrectly requires foo and causes false type errors for consumers.

Useful? React with 👍 / 👎.

All required controls is whether the emitted property has a ? suffix, and AFAIK there's no point in having an any-typed property be optional.

All required controls is whether the emitted property has a ? suffix, and AFAIK there's no point in having an any-typed property be optional.